Machine to Machine (M2M) and Internet of Things (IoT) covers a huge set of devices that communicate with each other and with networks based on various communication or access media, both as short range technologies and long range technologies.
Lightweight (LW) M2M is a new standard from the Open Mobile Alliance (OMA) that is focused on constrained cellular and other M2M devices. The standard defines an efficient device-server interface based on open Internet Engineering Task Force (IETF) standards i.e. Constrained Application Protocol (CoAP) and Datagram Transport Layer Security (DTLS). An LWM2M enabler includes device management and service enablement for LWM2M Devices. This enabler makes use of a light and compact protocol as well as an efficient resource data model.
IEC 62056 is a set of standards for Electricity metering data exchange by International Electrotechnical Commission. The IEC 62056 standards are the International Standard versions of the so-called DLMS/COSEM specification. Device Language Message Specification (DLMS) is the suite of standards developed and maintained by the DLMS User Association.
COSEM or Companion Specification for Energy Metering includes a set of specifications that defines the Transport and Application Layers of the DLMS protocol. The DLMS User Association defines the protocols into a set of four specification documents namely Green Book, Yellow Book, Blue Book and White Book. The Blue book describes a COSEM meter object model and an object identification system (OBIS), the Green book describes the Architecture and Protocols, the Yellow book treats all the questions concerning conformance testing, while the White book contains the glossary of terms.
Some of the key points pertaining to machine to machine communication involve:
M2M ecosystem consists of a variety of devices ranging from home automation, transportation, healthcare etc. These devices include fixed and mobile devices that can communicate over short or long range technologies.
The traffic or payload generated by M2M devices consists of messages with small size but numerous in nature. Also, the number of such devices (projected 50 Billion by 2020) require that the network usage shall be optimum in nature to efficiently and effectively use network resources.
LWM2M enabler has evolved as a standard specification that captures a set of interfaces and an efficient payload based on a simple flat client server architecture.
Typically communication is provided as a client-server type of communication, where a device having data to report, acts as a client entity and the device that receives the data acts as a server entity. Communication may here typically take place according to the OSI model, so that a client entity is a client access point communicating with a server access point via a communication medium using the OSI model.
The communication types supported by COSEM client/server are:
3-Layer, Connection Oriented (CO), HDLC based profile communication type
TCP-UDP/IP based communication type
S-FSK PLC based communication type
The 3-Layer, CO, HDLC based communication type is suitable for local data exchange with metering equipment via direct connection, or remote data exchange via the PSTN or GSM networks.
The TCP-UDP/IP based communication type is suitable for remote data exchange with metering equipment via IP enabled networks (for example Internet), using various communication networks, such as Local Area Networks or public or private Wide Area Networks.
The S-FSK PLC communication type is intended for remote data exchange over the low voltage electricity supply network between data concentrators located in MV/LV substations and meters connected to the LV network.
All the above mentioned communication types may also need communication type settings such as IP addresses and port numbers. The combination of communication type and setting may be termed a communication profile.
As can be seen above, there is support for one or more communication profiles. However, the mechanism for selection of which communication profile to apply is administrative in nature and there is no support to dynamically decide on which communication profile to activate and any rules for how to determine communication profile.
It is in view of what has been stated above a need for ways of selecting communication type to use in order to allow the implementation of more efficient M2M use.